home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940098.txt < prev    next >
Internet Message Format  |  1994-11-13  |  15KB

  1. Date: Tue,  5 Apr 94 04:30:12 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #98
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Tue,  5 Apr 94       Volume 94 : Issue   98
  11.  
  12. Today's Topics:
  13.                        Baycom modem and AMTOR?
  14.                           CDE antenna rotor
  15.                   Heathkit HD-15 Phonepatch Manual?
  16.                              JNOS and SAM
  17.                           MFJ 120C & Netrom
  18.                           Unknown RTTY mode
  19.  
  20. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  21. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  22. Problems you can't solve otherwise to brian@ucsd.edu.
  23.  
  24. Archives of past issues of the Ham-Digital Digest are available 
  25. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  26.  
  27. We trust that readers are intelligent enough to realize that all text
  28. herein consists of personal comments and does not represent the official
  29. policies or positions of any party.  Your mileage may vary.  So there.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: Tue,  5 Apr 94 12:52:58 +0400
  33. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!EU.net!news.eunet.fi!news.spb.su!satisfy.kiae.su!kiae!relcom!demos1!dnews-server@network.ucsd.edu
  34. Subject: Baycom modem and AMTOR?
  35. To: ham-digital@ucsd.edu
  36.  
  37.               Does anyone have the info about the possibility to
  38.             operate AMTOR with a simple modem in "Baycom" style.
  39.               Here is home made modem based on TCM3105 with an
  40.             external modulator (for 300 baud) on 2 IC's and an
  41.             active filters on 386/7 dx 40mHz at clone.
  42.               It's working well PR with software Baycom V1.5
  43.             and RTTY with Hamcomm V2.1, but i am still looking
  44.             for any other software, which allow to operate with a
  45.             "normal" terminal program, such a SP,GP... or in any
  46.             other mode (AMTOR, PACTOR)
  47.               I can't find this info here on local  VHF BBS,
  48.             because the nearest one located abt 200 km from here.
  49.               So it is only one way to find it - this place.
  50.  
  51.                Thank's
  52.                Andrey Petrov, UA1TFA.
  53.  
  54.              Russia
  55.              Novgorod State University
  56.              pap@pltx.nov.su
  57.  
  58. ------------------------------
  59.  
  60. Date: Mon, 4 Apr 1994 21:20:57 GMT
  61. From: amd!news.kpc.com!kpc!nat@decwrl.dec.com
  62. Subject: CDE antenna rotor
  63. To: ham-digital@ucsd.edu
  64.  
  65. Hi,
  66.     I bought a CDE antenna rotor at a hamfest last year. The rotor is
  67. fine but the controller seems to be flaky when I try to point the antenna
  68. between N and West. Here are the details from the back of the controller.
  69.     
  70.     Model AR-33    115 V.A.C
  71.     60 cycle       1 Amp
  72.     Mfd by
  73.     Cornell-Dubilier
  74.     Electronics Div.
  75.     Federal Pacific Electric Co.
  76.     Fuquay-Varina, North Carolina.
  77.     Patent No. 3.043,998
  78.  
  79.     Series 1820.
  80.  
  81.     The terminal strip has 5 wires. If anybody has a copy of the schematics
  82. of the controller I'd like to get a copy of it. Could some knowledgeable soul
  83. explain how the 5 wire system works. I opened the controller and the 
  84. position dial is nice wire wound resistor of 1K ohm resistance which has
  85. been hooked up as a variable resistor and not a potential devider. There is
  86. a large capacitor across terminal 1 and 5. There is a transfromer with a 
  87. center tapped secondary. The outer terminals are connected to terminals 2 and 4.
  88. Voltage between one of the outer terminals and the center tap is 14.2 volts.
  89. The center tap is connected to a ground trace on the circuit board.
  90.  
  91.     Is the controller setup as a bridge where the dial in the controller
  92. is one of the arms and a similar dial up in the rotor is the other arm.
  93. The rotor stops moving when the 2 arms get balanced. Any information will be
  94. of great help
  95.  
  96.     Sincerely
  97.     Nat.
  98.  
  99. -- 
  100. -------------------------------------------------------------------------
  101. Natarajan Gurumoorthy    AB6SJ        Kubota Pacific Computer, Inc.
  102. nat@kpc.com                2630 Walsh Avenue
  103. Phone 408 987 3341            Santa Clara, California 95051.
  104.  
  105. ------------------------------
  106.  
  107. Date: Mon, 4 Apr 1994 20:16:30 GMT
  108. From: agate!howland.reston.ans.net!wupost!crcnis1.unl.edu!news.unomaha.edu!news.nevada.edu!jimi!envoy!jim@ames.arpa
  109. Subject: Heathkit HD-15 Phonepatch Manual?
  110. To: ham-digital@ucsd.edu
  111.  
  112. I recenly aquired a Heath HD-15 phone patch without a manual.  Is there 
  113. someone who would make a copy for me?  I will gladly pay expenses.  Thank 
  114. you very much.
  115.  
  116.  
  117. -- 
  118. -------------------------------------------------------------------------------
  119.  Jim Mueller      | Work : (702) 689-3111 | jim@shadow.scs.unr.edu
  120.  11865 Deodar Way | Home : (702) 677-2775 | WB7AUE@KE7KD.#NONEV.NV.USA.NOAM
  121.  Reno, NV  89506  |                       |  
  122.  
  123. ------------------------------
  124.  
  125. Date: 5 Apr 1994 03:01:12 GMT
  126. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!news1.oakland.edu!chaos!ron@network.ucsd.edu
  127. Subject: JNOS and SAM
  128. To: ham-digital@ucsd.edu
  129.  
  130. John Martin (martin@server.cdpa.state.ms.US) wrote:
  131. : One other problem though. The command prompt is not cleared (ie, it still 
  132. : contains the command just entered) whenever the command causes you to 
  133. : switch to another session. When I return to the console screen the previous 
  134. : command is still on the command line following the prompt. The command IS 
  135.  
  136. Look on some archive sites for a patch for Borland C++ 2.0. This sounds just
  137. like the problem that one of their library files had.  I used to have to put
  138. the patch on it when I ran 2.0,  I'm running Borland C++ 3.1 now and it
  139. works fine.
  140.  
  141. : 73 - John
  142.  
  143. 73  Ron  N8FOW
  144.  
  145. ------------------------------
  146.  
  147. Date: 5 Apr 94 03:00:58 GMT
  148. From: dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@ucbvax.berkeley.edu
  149. Subject: MFJ 120C & Netrom
  150. To: ham-digital@ucsd.edu
  151.  
  152. In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says:
  153.  
  154. >I saw some messages the last couple fo week giving detailed instructions 
  155. >on how to get the MFJ1270C TNC to run as a netrom node.  
  156. >
  157.  
  158. To use the MFJ1270C with netrom or TheNET, all you need to do is program
  159. a 27256 EPROM with the modified firmware module (V2.08B is the one I have
  160. in three digi's in central IL) and plug it in.  No circuit mods are 
  161. required.
  162.  
  163. Installing an X1J node is another matter...
  164.  
  165. 73, Drew
  166.  
  167. -- 
  168. *-----------------------------*-------------------------------------*
  169. |    Andrew B. White  K9CW    |    internet: k9cw@prairienet.org    |
  170. |    ABW Associates, Ltd.     |   phone/fax: 217-643-7327           |
  171. *-----------------------------*-------------------------------------*
  172.  
  173. ------------------------------
  174.  
  175. Date: Mon, 4 Apr 1994 16:18:29 GMT
  176. From: rit!sunsrvr6!jdc@cs.rochester.edu
  177. Subject: Unknown RTTY mode
  178. To: ham-digital@ucsd.edu
  179.  
  180. In article <wilsonjhCnGKA1.Ix4@netcom.com>,
  181. John Wilson <wilsonjh@netcom.com> wrote:
  182. >I have been monitoring some "utility" signals using an AEA PK232-MBX, 
  183. >and have run across many strong signals that the PK232 cannot decode.
  184. >These sound like ordinary two-tone FSK RTTY signals.
  185. >They are often, but not always in the HF maritime bands (6, 8, 12, etc.
  186. >Mhz), and the signal identification feature on the PD232 shows
  187. >75 baud and mode "unknown". I hear these signals with both narrow
  188. >and wide shifts. Anybody know what they are? A special code for an
  189. >Oriental language? Encrypted data? Something altogether else? Anybody
  190. >know how to copy them?
  191. >
  192. >Tnx es 73,
  193. >John K3KXJ
  194.  
  195. I have also run into these signals.  I always thought the inability
  196. to decode them was due to shortcomings in hardware interface and
  197. software.  (I use Hamcom 2.2 with the 741 op-amp interface.)  But
  198. this may not be the case.  
  199.  
  200. After receiving the last half of a weather-fax map, the station switched 
  201. to RTTY.  It was strong signal, and the weather-fax came in OK.  After
  202. it switched to RTTY I fired up Hamcom 2.2.  It was easy to figure out
  203. frequency shift and baud rate with the "Spectrum" and "Bit length"
  204. screens.  But the text was undeciperable gobbledygook.
  205.  
  206. Seems like it must be some type of maritime-related station.  Anybody
  207. have more specific info?
  208.  
  209. 73...Jim  N2VNO
  210.  
  211. ------------------------------
  212.  
  213. Date: Mon, 4 Apr 1994 22:17:24 GMT
  214. From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!uhog.mit.edu!news.mtholyoke.edu!world!dts@network.ucsd.edu
  215. To: ham-digital@ucsd.edu
  216.  
  217. References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>.mthol
  218. Subject : Re: NTS traffic on packet
  219.  
  220. In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
  221. >In article <CnJL6K.Loq@world.std.com>, dts@world.std.com (Daniel T Senie) writes:
  222. >|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) writes:
  223. >|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote:
  224. >
  225. >|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to
  226. >|> my STM at the other end of the section got there 4 times. We have had
  227. >|> a rash of multiple NTS deliveries.
  228. >
  229. >This is a very serious problem.
  230. >
  231. >There are many possible causes, but they all come down to poor operating
  232. >practices by the sysops.  If the sysops had things set up reasonably,
  233. >and made certain their systems were operating properly, then there would
  234. >be no (zero, zilch, none) duplicated bulletins.
  235. >
  236. >Personal messages and NTS traffic are handled differently.
  237. >Duplicates are allowed to occur, rather than lose an occasional message.
  238. >However, these duplicates should be rare: 1 in 1000 perhaps.
  239.  
  240. This raises some alarm bells with me. Networks need to either send or not
  241. send messages. Protocols are designed to be able to be sure of such things.
  242. Could you imagine if something like an international money transfer were
  243. occasionally duplicated on the commercial networks? It sounds like the
  244. protocols involved (in nthis case, the handling methods) may need some
  245. review.
  246.  
  247. Why is the software designed to allow even an occasional duplicate? Why
  248. is there otherwise the possibility of a lost message?
  249.  
  250. >
  251. >Sounds like the sysops involved have not done a very good job of
  252. >getting their systems to work.
  253. >
  254. >You can't just "Load the BBS software and away you go."
  255. >It takes thought, planning, cooperation, and coordination to make a network
  256. >work properly.  In the past couple years, I have noticed a distinct lack of
  257. >all of the above in many parts of the BBS network.
  258. >
  259. >Perhaps time for some organization to take a leadership postion here?
  260. >
  261. >(ARRL, where are you when you are needed?)
  262.  
  263. Well, I am the local ARRL person (Section Manager). I'm gathering information
  264. so that I can intelligently address the appropriate people about the
  265. problem.
  266.  
  267. In this area the North East Digital Association runs the AX.25 net, so it 
  268. would seem to make sense that they are the ones to take the leadership
  269. position on this. Perhaps I need to appoint an Assistant Section Manager
  270. who can oversee packet operations, or something like that...
  271.  
  272. >
  273. >   ...  Hank
  274. >
  275. >-- 
  276. >
  277. >Hank Oredson @ Mentor Graphics
  278. >Internet     : hank_oredson@mentorg.com
  279. >Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
  280.  
  281. Thanks for your response, by the way. I do appreciate that you and others
  282. put in quite a bit of time on the BBS software. Overall things seem to work
  283. pretty well, but it gives a false sense of security sometimes, when things
  284. like the multitude of dupes we've seen happen.
  285.  
  286. thanks and 73,
  287.  
  288. Dan N1JEB SM WMA
  289. -- 
  290. ---------------------------------------------------------------
  291. Daniel Senie                 Internet:     dts@world.std.com
  292. Daniel Senie Consulting                    n1jeb@world.std.com
  293. 508-779-0439                 Compuserve:   74176,1347
  294.  
  295. ------------------------------
  296.  
  297. Date: Mon, 4 Apr 1994 22:24:16 GMT
  298. From: spsgate!mogate!newsgate!dtsdev0!kinzer@uunet.uu.net
  299. To: ham-digital@ucsd.edu
  300.  
  301. References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>ev0
  302. Subject : Re: NTS traffic on packet
  303.  
  304.  
  305.   All I can say is I'm glad no one is charged with maintaining the 
  306. ionosphere.  Just imagine the bitching out they'd get.
  307.  
  308.   I do have one positive contribution to make.  If duplicate messages are
  309. really a big problem, then each (or each destination) node could keep a
  310. hash code of the content of every message that has been seen in the past 
  311. N days.  If any hash code matches, delete the message without passing
  312. it along or making it available for download.  Ignoring headers allows 
  313. messages that have taken different routes to still be zapped.  Using a 
  314. good hash and enough bits and enough days history you could select the 
  315. probability of erroneously dropping a non-duplicate to less than the 
  316. probability of an NTS operator accepting a message yet dying before he 
  317. delivers it.
  318.  
  319.   Say 12 bits for date received (would allow over 10 years of data to
  320. accumulate and still allow for deleting by day, talk about overkill) and
  321. 52 bits of hash for a total of 8 bytes retained per message.  If 100
  322. messages arrived daily, and we kept 120 days worth, we would be keeping
  323. 96K bytes of data, not even a floppy disk worth.  There would be 12,000
  324. hash patterns (no duplicates) from a data space of 2^52, giving the
  325. possibility of erroneously deleting a random incoming message of
  326. 0.000000000266 percent.  Add a few more bits to the hash code if that's
  327. not good enough for you.  Even as it is, at 100 messages daily, it means 
  328. only one dropped message every 10 million years on average.  I don't think 
  329. this will be the weak link in delivering messages.
  330.  
  331.   Of course, I don't claim to be a mathematician or statistician, so the
  332. above numbers should be taken as a general approximation at best.  Still,
  333. it's one avenue open for exploration.
  334.  
  335. -dave
  336.  
  337. ------------------------------
  338.  
  339. Date: 5 Apr 1994 02:20:07 GMT
  340. From: nothing.ucsd.edu!brian@network.ucsd.edu
  341. To: ham-digital@ucsd.edu
  342.  
  343. References <2n7bup$3v3@hpbab.mentorg.com>, <1994Mar29.100554.3059@hemlock.cray.com>, <2nphhd$djt@hpbab.mentorg.com>
  344. Subject : Re: [REPOST] The # in PBBS addresses....
  345.  
  346. In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
  347. >You are perhaps talking about the internet, which chose to ignore
  348. >the existing use of NA in one of it's connected networks?
  349.  
  350. Oh jeez, Hank, stop making things up.  The AMPR.ORG domain has never used
  351. the ham bbs hierarchical routing/addressing scheme to name hosts.
  352.  
  353. With some exceptions, the namespace of the AMPR.ORG domain consists
  354. solely of callsigns within the domain.  Names are not routes, routes
  355. are not names, and mixing them up is one of the worst possible mistakes
  356. a network architect could make.
  357.  
  358. That means that whilst you might see
  359.     W0RLI.AMPR.ORG
  360. or
  361.     BBS.W0RLI.AMPR.ORG
  362. you won't see
  363.     W0RLI.#NNJ.NJ.USA.NOAM.AMPR.ORG
  364. or the like
  365.  
  366. Ever.
  367.         - Brian
  368.  
  369. ------------------------------
  370.  
  371. End of Ham-Digital Digest V94 #98
  372. ******************************
  373.